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I. Real Party in Interest 

The present application is assigned to Hewlett Packard. 

II. Related Appeals and Interferences 

The Appellants' legal representative does not know of any other appeal or 
interference which will affect or be directly affected by or have bearing on the 
Board's decision in the pending appeal. 



IV. Status of Amendments 

An Amendment After Final was filed March 23, 2004 wherein the only 
amendment was directed to replacing the title to address the Examiner's objection in 
the Final Office Action. In an Advisory Action dated April 2, 2004, the Examiner 
refused entry of the proposed Amendment because it was "not deemed to place the 
application in better form for Appeal by materially reducing or simplifying the issues 
for Appeal". 

A Substitute Amendment After Final is submitted hereto to reintroduce the 
proposed change of Title. Entry of this Amendment is requested to reduce the 
number of issues on appeal. 

V. Summary of the Invention 

The present application discloses systems and methods for minimizing the 
response time of an application module, such as an Internet server which hosts 
applications accessed by remote user terminals, or clients. Exemplary embodiments 
include a network interaction module and an external queue. The network 
interaction module is used to "fetch" external requests from the external queue, and 
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Claims 1-20 remain rejected. 
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to determine which requests will not be processed based on, among other 
features, the processing capacity of the application module and the rate at which 
external requests arrive at the external queue. 

Referring to Appellants' Figure 3, an exemplary embodiment is disclosed 
which includes a data server system 40 having a server application system 44 
connected to an external kernel 41. The kernel 41 includes an external queue 42 
which functions as a TCP listen queue. The queue is external to the server 
application system 44, and stores external TCP connection requests (e.g., client 
requests to the data server system 40) before the requests are fetched into the 
server application system 44 for processing. The server application system 44 
includes a network interaction module 45 connected to the external queue 42. 

With this configuration, the network interaction module 45 can selectively 
assess external connection requests stored in the external queue 42 to determine 
which requests will not be processed. Requests can effectively be screened by the : 
server application system 44 before they are fetched for service by the server 
application 44, as described at specification page 7, lines 18-25. 

The network interaction module 45 can determine which fetched requests will 
not be processed by the application module 46 based on the processing capacity of 
the application module 46 and the rate at which the external requests arrive at the 
queue 42. As described at page 8, line 1 1 -page 9, line 3, after determining which 
requests will not be processed, the module 45 fetches all requests from the external 
queue. If the module 45 can not store all of the new requests, any such requests 
which can not be stored are also treated as not-to-be processed requests. Network 
interaction module 45 closes the TCP connection associated with a rejected request 
or sends a rejection response with status information (page, lines 4-11). Thus, 
exemplary embodiments do not simply reply on conventional TCP/IP techniques for 
processing requests, but are proactive in actually determining which requests will not 
be processed. 
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These features are broadly enconnpassed by claim 1 . Claim 1 recites a 
TCP/IP-based application system which includes, among other features, a network 
interaction module (such as server network interaction module 45) coupled to an 
application module (such as application module 46) and an external queue (such 
as listen queue 42) to fetch external requests from the external queue into the 
application system. The network interaction module determines which, if any, of 
the fetched requests will not be processed by the application module based on 
the processing capacity of the application module and the rate of the external 
requests arriving at the external queue. 

Claim 14 recites a TCP/IP based application system wherein a method of 
minimizing a response time of the application system to external requests is recited. 
In addition to reciting features similar to those recited with respect to claim 1 , claim 
14 also recites periodically fetching all of external requests stored in the external 
queue. By fetching all of the requests stored in the external queue, such as queue 
42, the possibility of TCP time outs and the possibility of requests stored in the 
external queue being dropped, can be minimized, as described at specification page 
9, lines 15-22. 

Exemplary embodiments encompassed by Appellant's claims provide 
numerous advantages including, an ability to minimize the response time of an 
application module (e.g., application server) to external requests as described at 
specification page 9, lines 4-14. In addition, exemplary embodiments allow an 
application module to decide which, if any, of the external requests should be denied 
service, rather than leaving such a determination to fall upon the system's TCP/IP 
stack in kernel 41, as described at page 9, line 22-page 10, line 1 . Exemplary 
embodiments can ensure that process delays due to a heavy demand on a server 
will not be misinterpreted as an overload of the network interconnect. 
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VI. The Issues 

Whether U.S. Patent No. 6,321,272, Relied Upon Under 35 U.S.C. §1 02(e), 
Discloses Each And Every Elennent Of Independent Claims 1 and 14 

VII. Grouping of Claims 

Each of the Appellant's claims recites a novel combination of elements, and 
must be considered independently on its merits. For example, Appellant's 
independent claims 1 and 14 must be considered separately. Because these claims 
are considered patentable, all arguments which apply to these claims necessarily 
apply to all of the remaining claims. 

VIII. Argument 

U.S. Patent No. 6,321,272, Relied Upon Under 35 U.S.C. §1 02(e), Fails To 
Disclose Each And Every Element Of Independent Claims 1 and 14 

Appellants' independent claims 1 and 14 recite features that are neither 
taught nor suggested by the Swales patent. For example, the Swales patent does 
not teach or suggest, among other features, a network interaction moduie coupled 
to an application module and an external queue (1) to fetch external requests from 
the external queue into the application system and (2) to determine wliich, if any, 
of the fetched requests will not be processed by the application module based on 
the processing capacity of the application module and the rate of the external 
requests arriving at the external queue. 

1 . The Final Rejection 

On pages 2-4 of the Final Office Action dated December 24, 2003 (Paper No. 
8), the Examiner sets forth the basis for rejecting claims 1-20 as being anticipated by 
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the Swales patent. In the last six lines of the paragraph bridging pages 2-3, the 
Examiner states: 

Swales teaches processing based on processing capacity and rate of 
requests, col. 11, lines 30-34, col. 12, lines 43-45, col. 13, lines 4-7, 
34-38. 



On page 4 of the Final Office Action, the Examiner asserts in numbered 
paragraph 18 that "The broad claim language used is interpreted on its face and 
based on this interpretation the claims have been rejected." 

On page 5 of the Final Office Action, the Examiner asserts in numbered 
paragraph 20: 

Applicant suggests "the Swales patent fails to teach or suggest ... 
processing capacity of the application module and the rate of the 
external requests arriving at an external queue", Paper No. 6, Page 
14, lines 3-4. ... Specifically, Swales teaches applying processing 
capacity as "load factors", col. 11, line 33 "by controlling the reported 
transmission window as seen by both participants in a connection", col. 
14, lines 30-3 1 and rate of requests as "the number of participants can 
be calculated", col. 13, lines 37-38. The capacity of the network is 
inherently determined by monitoring relevant elements and the 
teachings clearly are not limited to the network itself in general. 



During an Examiner Interview conducted April 2, 2004, distinguishing features 
of the presently claimed invention as set forth in the Amendment After Final filed 
March 23, 2004 were emphasized. An Examiner Interview dated April 2, 2004 
indicated that no agreement was reached, and stated: 

The representative argued that fetching based on rate of external 
requests and processing capacity are not taught [in the Swales patent]. 
The examiner referred to col. 12, lines 43-44 of Swales as teaching 
rate of requests by "slowing down traffic" based on "network loading". 
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The foregoing comments of the Examiner overlook the existence of specific 
claim language which clearly distinguishes over the Swales patent. 

2. The Swales Patent 

The Swales patent is directed to providing an interface between a non-real 
time portion and a real time portion of a network, wherein the interface is used to 
restrict the flow of messages from the non-real time portion into the real time portion 
of the network. Referring to the Abstract of the Swales patent, a proxy server is 
described as being configured to control the rate at which messages are fonA/arded 
from the non-real time portion to the real time portion of the network to keep loading 
on the real time portion stable. However, the proxy server is described throughout 
the Swales patent as implementing flow control of messages using conventional 
TCP (as described in the Background portion of Appellants' specification) and 
proxies with private networks. There is no server in the Swales patent which 
performs a function of deternnining which requests fetched in an external queue of 
an application module will not be processed based on the processing capacity of 
the application module and the rate of the external requests arriving at the 
external queue. 

For example, the proxy server of the Swales patent does not determine 
requests which will not be processed. Moreover, the proxy server does not make 
any determinations based on processing capacity of an application module and the 
rate at which external requests are arriving at any external queue. 

In Figure 1 of the Swales patent, Internet 14 connects a client computer 8 
with a server 20 of a website 4. The portions of the Swales patent relied upon by the 
Examiner describe using conventional techniques, such as TCP and proxies, for 
servicing a client request via a TCP/IP stack. TCP achieves flow control by dropping 
packets before they are acknowledged by a server. TCP forces clients to back-off 
sending data using, for example, an exponential back-off algorithm. This is precisely 
the behavior which Appellants' systems minimize, by having a network interaction 
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module interface with an external queue to proactively determine requests which will 
not be processed. 

Conventional TCP techniques result in dropped connections, and in a client 
backing off from sending requests when requests made by the client go 
unacknowledged. These techniques do not provide a server with an ability to 
determine which requests will not be processed as a function of processing capacity 
and rate of external requests received. 

As described at column 4, lines 3-13 of the Swales patent, server 20 uses 
TCP in conjunction with IP, through TCP/IP stack 24, to Interact with network 
interface 16 and application program 22. The Swales patent is directed to 
monitoring delays due to traffic on the Internet connection, and is not concerned with 
the manner by which a server processes the requests that it receives, 

A web server 30 of a Figure 2 embodiment in the Swales patent is illustrated 
in Fig. 3 as including TCP/IP stack 54. According to column 5, lines 38-44 of the 
Swales patent, conventional TCP/IP techniques are described. For example, 
column 7, lines 1 1-14 of the Swales patent describes using a TCP/IP stack with the 
Berkley interface having signal extensions. This is a standard socket interface that 
allows for packet dropping and TCP/IP back-off (whereby a client begins to back off 
sending additional requests) for flow control. 

Figure 4 shows use of a generic purpose proxy 22 to interface a 
programmable logic controller (PLC) 80 of a real time portion of a network with a 
non-real time portion (represented as Internet 14 and intranet 74). See col. 10, 
lines 24-41 . Figure 5 shows a similar system with proxy 116, wherein flow control is 
maintained using TCP and proxies with private networks, as described at column 12, 
lines 21-22. It is this flow control which is used to "slow down traffic" as mentioned 
at column 12, lines 43-44. The proxy does not determine the capacity of a server or 
the rate at which external requests are arriving at an external queue. Rather, the 
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flow control is used to restrict traffic flow from the non-real time portion of the 
network, as described in the last two sentences of the Abstract in the Swales patent. 

Thus, the Swales patent does not teach or suggest a mechanism for dealing 
with a number of requests received at a server which exceed a capacity of the 
server. Rather, network loading is restricted using known TCP and proxies to 
provide flow control. 

3. Analysis Of Claims 1 and 14 

Swales provides no teaching or suggestion of Appellants' claimed network 
interaction module for fetching requests from an external queue and for 
determining which requests will not be processed by an application module 
based on the processing capacity of the application module and the rate of external 
requests arriving at an external queue. Appellant's claimed invention overcomes 
the shortcoming of a system like Swales, wherein a request will go repeatedly 
unserviced until the client stops sending them. 

The Swales patent uses terms such as "closed connections", "dropped 
connections" and "aborted connections." This relates to the TCP/IP mechanisms, 
and does not constitute determining which requests fetched from an external queue 
will not be processed by an application module based on processing capacity of the 
application module and the rate of external requests arriving at the external queue. 
According to the techniques disclosed in the Swales patent, a client and not a 
server, is responsible for controlling the amount of traffic flow on the network. 

Thus, Swales provides no teaching or suggestion to provide Appellants' 
claimed network interaction module for determining which requests fetched from an 
external buffer will not be processed by an application module based on the 
processing capacity of the application module and the rate of external requests 
arriving at an external queue. As such, independent claim 1 is allowable. 
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In independent claim 14 recites features similar to those discussed with 
respect to claim 1. In addition, claim 14 recites, among other features, periodically 
fetching all of external requests stored in an external queue external to the 
application system into an internal queue of the application system. Claim 14 also 
recites rejecting requests not to be processed such that the possibility of dropping a 
request from an external queue is minimized and the response time of the 
application system to the requests is minimized. Such features are neither taught 
nor suggested by the Swales patent. As such, claim 14 is also allowable. 

4. The Dependent Claims 

All of Appellants' dependent claims recite additional advantageous features 
which further distinguish over the Swales patent. Because these dependent claims 
incorporate features of independent claims 1 and 14, for at least the reasons set 
forth above, these claims are allowable. 

IX. Conclusion 

Reversal of the Examiner's rejection and allowance of claims 1-20 are 
respectfully requested. 



Respectfully submitted, 

Burns, Deane, Swecker & Math is, L.L.P. 



Date June 28, 2004 




Patrick C. Keane 
Registration No. 32,858 



P.O. Box 1404 

Alexandria, Virginia 22313-1404 
(703) 836-6620 
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APPENDIX A 



The Appealed Claims 

1 . (Original) A TCP/IP-based application system, comprising: 

an application module that performs predetermined functions based on 
external requests from an external queue, the external queue being external to the 
application system and storing the external requests before the requests are fetched 
into the application system; 

a network interaction module coupled to the application module and the 
external queue (1) to fetch the external requests from the external queue into the 
application system and (2) to determine which, if any, of the fetched requests will not 
be processed by the application module based on the processing capacity of the 
application module and the rate of the external requests arriving at the external 
queue. 

2. (Original) The TCP/IP-based application system of claim 1 , wherein 
the network interaction module rejects those requests determined not to be 
processed by the application module. 

3. (Original) The TCP/IP-based application system of claim 2, wherein 
the network interaction module rejects the requests not to be processed by closing 
their connections. 
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4. (Original) The TCP/IP- based application system of claim 2, 
wherein the network interaction module rejects the requests not to be processed by 
returning a rejection response with a status code. 

5. (Original) The TCP/IP-based application system of claim 4, wherein 
the rejection response returned by the network interaction module is a HTTP 
response. 

6. (Original) The TCP/IP-based application system of claim 1 , wherein 
the network interaction module also determines which of the fetched requests will be 
processed first by the application mode. 

7. (Previously Amended) The TCP/IP-based application system of claim 
1, wherein the network interaction module further comprises: 

an internal queue of a predetermined length that receives and stores the 
external requests fetched from the external queue; 

a decision module that (1) causes the external requests to be fetched into the 
internal queue and (2) determines which of the fetched requests will be processed 
by the application module and which of the fetched requests will not be processed 
by the application module based on the processing capacity of the application 
module and the rate of the external requests arriving at the external queue; 

a notification module that requests the requests that are determined not to be 
processed. 
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8. (Original) The TCP/IP-based application system of ciainri 7, wherein 
the length of the internal queue is at least equal to that of the external queue. 

9. (Original) The TCP/IP-based application system of claim 1 , wherein 
the notification module rejects the requests that are determined not to be processed 
by either closing their connections or sending a rejection response with status code. 

1 0. (Previously Amended) The TCP/IP-based application system of claim 
7, wherein the decision module determines which of the fetched requests will not be 
processed by the application module by: 

reducing the number of requests to be processed by the application module if 
new requests are received in the external queue, wherein the number is previously 
determined and cannot be less than one; 

increasing the number of requests to be processed by the application module 
if no new requests are received in the external queue, wherein the number cannot 
exceed the length of the external queue; 

storing remaining unprocessed requests in the internal queue; 

fetching all new request from the external queue into the internal queue and 
causing all of the newly fetched request that cannot be stored in the internal queue 
not to be processed. 

1 1 . (Original) The TCP/IP-based application system of claim 1 0, 
wherein the number of requests to be processed is either increased or reduced by a 
factor of two. 
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12. (Previously Amended) The TCP/IP-based application system of claim 

1 , wherein the network interaction module determines which of the fetched requests 
will not be processed by the application module by: 

reducing the number of requests to be processed by the application module if 
new requests are received in the external queue, wherein the number is previously 
determined and cannot be less than one; 

increasing the number of requests to be processed by the application module 
if no new requests are received in the external queue, wherein the number cannot 
exceed the length of the external queue; 

storing remaining requests in an internal queue; 

fetching all new requests from the external queue into the internal queue and 
causing all of the newly fetched requests that cannot be stored in the internal queue 
not to be processed. 

13. (Original) The TCP/IP-based application system of claim 1 , wherein 
the number of requests to be processed is either increased or reduced by a factor of 
two. 



14. (Original) In a TCP/IP-based application system, a method of 
minimizing response time of the application system to external requests, comprising 
the steps of: 

periodically fetching all of external requests stored in an external queue 
external to the application system into an internal queue of the application system; 
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determining which, if any, of the fetched requests not to be processed by the 
application system based on the processing capacity of the application module and 
the rate of the external requests arriving at the external queue; 

rejecting the requests not to be processed such that the possibility of 
dropping a request from the external queue is minimized and the response time of 
the application system to the requests is minimized. 

15. (Original) The method of claim 14, wherein the step of rejecting the 
requests not to be processed is performed by closing their connections. 

16. (Original) The method of claim 14, wherein the step of rejecting the 
requests not to be processed is performed by returning a rejection response with a 
status code. 



17. (Original) The method of claim 16, wherein the rejection response 
is a HTTP response. 

18. (Previously Amended) The method of claim 14, further comprising: the 
step of determining which of the fetched requests will be processed first. 

19. (Previously Amended) The method of claim 14, wherein the step of 
determining which of the fetched requests are not to be processed further comprises 
the steps of: 
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reducing the number of requests to be processed if new requests are 
received in the external queue, wherein the number is previously determined; 

increasing the number of requests to be processed if no new requests are 
received in the external queue; 

storing remaining requests in an internal queue of the application system; 

fetching all new requests from the external queue into the internal queue and 
causing all of the newly fetched requests than cannot be stored in the internal queue 
not to be processed. 



20. (Original) The method of claim 19, wherein the number of requests 
to be processed is either increased or reduced by a factor of two. 



